Data network technology permits multiple users to share economically access to files in a number of file servers. Problems arise, however, in the assignment of files to particular servers. For example, it may be desirable to move a file from one file server to another when a new server is added to the network. A “CDMS” brand of data migration service provided by EMC Corporation of Hopkinton, Mass., can be used to move files from one file server to another while permitting concurrent client access to the files.
In a typical use of the EMC Corporation “CDMS” brand of data migration service, respective IP addresses are assigned to file servers. In order to migrate a file system from a source file server to a target file server, the IP address of the file server is reassigned from the source file server to the target file server, the file system is then mounted as a read-only file system in the source file server, and then the migration service is invoked in the target file server. The migration service in the target file server then begins a background process of using a protocol such as NFS, CIFS, HTTP or FTP to copy the files and directories from the read-only file system in the source file server to a temporary migration inode data structure in the target file server. The migration service in the target file server concurrently responds to client requests for access to a directory or file in the file system on a priority basis by checking the migration inode data structure to determine whether the directory or file has already been copied from the source file server to the target file server, and if so, then accessing the directory or file in the target file server, and if not, by fetching the directory or file from the source file server, storing the directory or file in the migration inode data structure in the target file server, and accessing the directory or file in the target file server. Once an entire file has been copied from the source file server to the target file server, the migration inode data structure for the file in the target file server is converted to a conventional inode data structure for the file in the target file server. The migration inode is converted to a conventional inode by allocating the conventional inode and initially setting an offline attribute bit of the conventional inode to indicate that the conventional inode is offline, transferring file system blocks associated with the migration inode to the conventional inode, deleting the migration inode, and clearing the offline attribute bit. Once all of the files of the file system have been copied from the source file server to the target file serve, the read-only version of the file system can be deleted from the source file server.
The EMC Corporation CDMS brand migration service uses a connection database for storing information about a connection over which file data is migrated between the source file server and the target file server. The connection database includes the following fields: for CIFS, the Server Name, Share name, User name, Password, Domain Server, and WINS server; and for NFS, the Server name, Path of exported share, Use Root credential flag, Transport protocol, Secondary server NFS/Mount port, Mount protocol version, and Local port to make the connection.
Files are also often moved between file servers in order to relocate infrequently accessed files from feature-rich, expensive, and highly-protected high-speed disk storage to more economical and possibly slower mass storage. In such a system, the high-speed disk storage is referred to as primary storage, and the mass storage is referred to as secondary storage. When a client needs read-write access to a file in the secondary storage, the file typically is moved back to the primary storage, and then accessed in the primary storage. This kind of migration of files between levels of storage in response to client requests based on file attributes such as the time of last file access and last file modification is known generally as policy-based file migration or more specifically as hierarchical storage management (HSM). It is desired for such policy-based or hierarchical storage management to be transparent to the clients, yet in practice there is always a trade-off between cost of storage and delay in file access.
In a data processing network employing hierarchical storage management, a client typically accesses a primary file server containing the primary storage, and the secondary storage is often in another file server, referred to as a secondary file server. When a file is moved from a primary file server to a secondary file server, the file in the primary file server is typically replaced with a stub file that contains attributes of the file and a link to the new file location in the secondary file server. The stub file can be accessed to redirect an access request from a client to the new file location in the secondary server, or to migrate data from the present file location back to the primary file server. This stub file can be a symbolic link file in a UNIX-based file system, or a shortcut file in a Microsoft WINDOWS file system. In a computer using the Microsoft WINDOWS operating system, access to a stub file may automatically result in access to the new file location. For example, an attempt to execute or open a shortcut will cause the Microsoft WINDOWS operating system to execute or open the target of the shortcut. Access of related files (i.e., object linking supported by OLE) can have problems of links that are easily broken when the end user manually changes the location of the related files.